[CData API Server実践編]AWS環境で本番環境を構築してみる
はじめに
データアナリティクス事業本部のkobayashiです。
REST API構築ツール CData API Server を下記のエントリにてWindowsの環境やEC2のAmazonLinux2で構築してみました。
これらの手順で簡単にAPIサーバーが構築でき開発やテスト環境としてはこの内容で十分なのですが、いざ本番環境となると
- HTTPなため平文でのデータのやり取りになっておりHTTPS化を行う
- 可用性と耐障害性を向上させる
が必要になってくるかと思います。今回はこの2点を満たし本番環境でCData API Serverが使用に耐え得る環境をElastic Load Balancing(今回はAplication Load Balancerを使用。以下ALB)とAmazon EC2 Auto Scalingを用いて作成します。
なお今回のエントリ内容は以下の記事を参考にさせていただいております。こちらも併せてご覧ください。
AWSとCDataで実現するスケーラブルなWebAPIサーバーの構築手順 - Qiita
環境
- Amazon Linux 2
- CData API Server - 19.0.7493.0
- RDS MariaDB 10.2.21
CData API Serverの本番環境構成
今回作成する構成は以下の図の様になります。
ポイントは以下になります。
- CData API ServerのアプリケーションデータをRDSへ保存する
- CData API ServerをインストールしたAMIを作成しAuto Scalingの起動テンプレートを作成する
- HTTPS化を行うためにAWS Certificate Managerで独自ドメイン用の証明書を発行しALBで使用する
- ALBをAuto Scalingグループ(AMIを使った起動テンプレート)にアタッチする
ALBで証明書を使うことになり外部からALBまではHTTPS化した通信が行えセキュアになります。また CData API Serverのアプリデータを個々のインスタンス内ではなく外部のRDSへ保存することで起動したインスタンスから共通のデータを使うことになりAuto Scalingでスケーリングが可能になります。
実際の作業は以下の手順で行います。
- ALB、Auto Scaling Group、RDSで使うセキュリティグループを作成する
- アプリデータを保存するRDSを作成する
- CData API ServerをインストールしたAMIを作成する
- ACMで証明書を発行する
- ロードバランサー(ALB)を作成する
- Auto Scaling Groupを作成する
1. ALB、Auto Scaling Group、RDSで使うセキュリティグループを作成する
これから行う設定で3種類のセキュリティグループが必要なので予め作成しておきます。
作成するセキュリティーグループはALB用、Auto Scaling Group用、RDS用の順番で作成します。
手順1-1). AWSマネージメントコンソールでEC2の画面へ進み、サイドバーのネットワーク&セキュリティ > セキュリティグループ
と進み、セキュリティグループを作成
を押下して作成画面へ進む。
手順1-2). ALB用のセキュリティグループを作成するため以下の内容を設定しセキュリティグループを作成
を押下しセキュリティーグループを作成する。
- セキュリティグループ名 : 適切な名前を入力
- 説明 : 適切な内容を入力
- VPC : ALB、Auto Scaling Group、RDSを作成するVPCを選択
- インバウンドルール :
ルールを追加
を押下し以下のルールを追加
タイプ | プロトコル | ポート範囲 | ソース |
---|---|---|---|
HTTPS | TCP | 443 | 0.0.0.0/0 |
手順1-3). 手順1-2と同じ作業でAuto Scaling Group用のセキュリティグループを作成するため以下の内容を設定しセキュリティグループを作成
を押下しセキュリティーグループを作成する。
- セキュリティグループ名 : 適切な名前を入力
- 説明 : 適切な内容を入力
- VPC : ALB、Auto Scaling Group、RDSを作成するVPCを選択
- インバウンドルール :
ルールを追加
を押下し以下のルールを追加
タイプ | プロトコル | ポート範囲 | ソース |
---|---|---|---|
カスタムTCP | TCP | 8080 | (先に作成したALB用のセキュリティーグループID) |
カスタムTCP | TCP | 8080 | (CDataをインストールする端末のIPアドレス) |
SSH | TCP | 22 | (CDataをインストールする端末のIPアドレス) |
手順1-4). 手順1-2と同じ作業でRDS用のセキュリティグループを作成するため以下の内容を設定しセキュリティグループを作成
を押下しセキュリティーグループを作成する。
- セキュリティグループ名 : 適切な名前を入力
- 説明 : 適切な内容を入力
- VPC : ALB、Auto Scaling Group、RDSを作成するVPCを選択
- インバウンドルール :
ルールを追加
を押下し以下のルールを追加
タイプ | プロトコル | ポート範囲 | ソース |
---|---|---|---|
MYSQL/Aurora | TCP | 3306 | (先に作成したAuto Scaling Group用のセキュリティーグループID) |
以上でセキュリティグループの作成が終わります。
2. アプリデータを保存するRDSを作成する
次にCData API Serverで作成されるログデータやユーザーデータなどを保存するRDSを作成します。今回は自分が使い慣れていることもありMariaDBを選択しましたがMySQLでも問題ありません。ただCData API Serverの標準ドライバで接続できるデータベースが良いと思うのでRDSでしたらMariaDB
かMySQL
、AuroraでしたらMySQL との互換性を持つ Amazon Aurora
を使うのが無難です。
手順2-1). AWSマネージメントコンソールでRDSの画面へ進み、サイドバーのデータベース
を押下しデータベースの作成
を押下し設定画面に進む
手順2-2). データベースの作成画面に遷移するので設定を行いデータベースの作成
を押下しデータベースを作成する。
- データベース作成方法を選択 :
標準作成
を選択 - エンジンのオプション
- エンジンのタイプ:
MariaDB
を選択 - バージョン :
MariaDB 10.2.21
を選択
- エンジンのタイプ:
- テンプレート : 運用に適切なものを選択(試しに行うなら
無料利用枠
を選択します) - 設定 :
- DBインスタンス識別子 : 適切な文字列を入力(接続先名になります)
- 認証情報の設定 : 適切な情報を入力(後に接続席情報で使います)
- DBインスタンスサイズ : 適切なものを選択(試しに行うなら
db.t2.micro
を選択) - ストレージ : 適切な設定を入力(試しに行うならデフォルトの設定で問題なし)
- 接続
- VPC : ALB、Auto Scaling Group、RDSを作成するVPCを選択
- サブネットグループ : 適切なものを選択
- パブリックアクセス可能 : なし
- VPCセキュリティグループ : 手順1-4で作成したセキュリティグループ
- アベイラビリティーゾーン : 適切なものを選択
- データベースポート : 3306
他の設定値はデフォルトのままにします。
3. CData API ServerをインストールしたAMIを作成する
インストールは以前のエントリにてまとめてありますのでそちらをご確認ください。
このエントリの続きから作業を行います。なお上記のエントリでライセンスについて詳しく解説を行いませんでしたが、AMIを作成してオートスケールを行うにはマシンIDをチェックしないライセンスが必要になりCData API Serverのライセンスには「CLOUDライセンス」が必要になります。
また標準のデータソース(SQLite、Apache Derby、MySQL、Excel)以外のデータソースを扱いたい場合は別途CData社のドライバが必要になります。その際にもマシンIDをチェックしないライセンスとしてJDBC URL にRTK(RunTimeKey)プロパティを設定する必要があり、RTKライセンスが必要になります。
手順3-1). CData API Serverへログインし、ヘッダーメニューから情報
へ進み、新しいライセンス
で押下しライセンス情報を入力する。その際に必ず「CLOUDライセンス」を購入して入力する。
手順3-2). 設定 > 接続
と進み標準以外のドライバでRTKライセンスを入力したい接続を選択する。
手順3-3). Advanced
タグを選択しOther
のセクションまで進むとRTK :
の項目があるのでRTKライセンスキーを入力し、接続チェックを行い接続が確認できたら変更を保存
で設定を保存する。
これでCData API Serverに関する設定は終わったのでこのインスタンスのイメージを作成してAuto Scalingで使います。
手順3-3). サイドバーのインスタンス
からインスタンス一覧を表示し、イメージを作成したいEC2インスタンスを選択する。アクション > イメージ > イメージの作成
と進みAMI作成モーダルを立ち上げる。
手順3-4). イメージ名
にわかりやすい名前を入力し、イメージの作成
を押下してイメージを作成する。
これでAuto Scalingで使用するAMIは作成できました。
4. ACMで証明書を発行する
次にHTTPS化を行うためALBに独自ドメイン用のSSL証明書を使いますがACMで発行します。その際に必要な独自ドメインはRoute53で管理されているとACMでの証明書発行が簡単です。今回はすでにドメインは取得済みでRoute53で管理されていることを前提としてACMでSSL証明書を発行する方法をまとめます。
手順4-1). AWSマネージメントコンソールでCertification Managerの画面へ進み、証明書のリクエスト
を押下し証明書のリクエスト
へ進む。
手順4-2). パブリック証明書のリクエスト
を選択し、証明書のリクエスト
を押下して先へ進む。
手順4-3). ドメイン名の追加画面でドメイン名
の欄に設定したいドメインを入力し次へ
を押下し進む。
手順4-4). 検証方法の選択画面に遷移するのでRoute53でドメインを管理しているならDNSの検証
を選択する。
手順4-5). Route 53でドメインを管理しているのでRoute 53でのレコードの作成
をクリックする。
(*もしRoute 53以外でドメインを管理している場合は個別にCNAMEを設定して下さい。)
手順4-6). 設定するRoute 53のホストゾーンとレコードの内容を確認後、作成
を押下する。
以上でACMでSSL証明書の発行の設定が終わります。しばらくするとドメインの検証が終わりACMのダッシュボードの画面で状況が発行済
となればSSL証明書が使えるようになります。
5. ロードバランサー(ALB)を作成する
次にロードバランサーとしてALBを設定します。
手順5−1). AWSマネージメントコンソールでEC2の画面へ進み、サイドバーのロードバランシング > ロードバランサー
と進み、ロードバランサーの作成
を押下して作成画面へ進む。
手順5-2). ロードバランサーの種類の選択画面にてApplication Load Balancer
の作成
を押下する。
手順5-3). ロードバランサーの設定画面に進むので必要情報を入力し、セキュリティ設定の構成
を押下して先へ進む。
- 名前 : わかりやすい名前を入力
- スキーム :
インターネット向け
を選択 - IPアドレスタイプ :
ipv4
を選択 - リスナー
− ロードバランサーのプロトコル :
HTTPS
を選択- ロードバランサーのポート :
443
を入力
- ロードバランサーのポート :
- アベイラビリティーゾーン :
- VPC : 適切なVPCを選択
- アベイラビリティーゾーン : 可用性を高めるために2つ以上選択
手順5-4). セキュリティ設定の構成へ進むので証明書タイプ
でACM から証明書を選択する (推奨)
を選択し、証明書の名前で手順4で設定した証明書の名前を選択する。セキュリティポリシーはデフォルトのままにし、セキュリティグループの設定
を押下して先へ進む。
手順5-5). セキュリティグループの設定画面に進むのでセキュリティグループの割当
で既存のセキュリティグループを選択する
を選択し、手順1−2で作成したセキュリティグループを選択し、ルーティングの設定
を押下し先へ進む。
手順5-6). ルーティングの設定画面に進むので設定を行い、ターゲットの登録
を押下する。
- ターゲットグループ
- ターゲットグループ :
新しいターゲットグループ
を選択 - 名前 : わかりやすい名前を入力
− ターゲットの種類 :
インスタンス
を選択 − プロトコル :HTTP
を選択 - ポート :
8080
を入力 − ヘルクチェック − プロトコル :HTTP
を選択 - パス :
/login.rst
を入力
- ターゲットグループ :
他はデフォルト値で問題ありません。パスですが/
ですとCData API Server側でリダイレクトが設定されているため303が返りヘルスチェックでunhealthy
となってしまうので注意してください。
手順5-7). ターゲットの登録画面に進みますが後の手順でAuto Scalingグループを設定するのでここでは何も設定せず進む。
以上でALBの設定が終わり、ALBとターゲットグループが作成されます。
6. Auto Scaling Groupを作成する
最後ににALBで使うAuto Scaling GroupをCData API ServerをインストールしたAMIを使ってインスタンスを起動するように作成します。
はじめに起動テンプレートを作成します。
手順6-1). AWSマネージメントコンソールでEC2の画面へ進み、サイドバーのインスタンス > 起動テンプレート
と進み、起動テンプレートを作成
を押下して作成画面へ進む。
手順6-2). 起動テンプレートを作成画面に進むので設定の中でAuto Scalingのガイダンス
にチェックを入れ設定を行う。起動テンプレートを作成
を押下する。
- 起動テンプレート名 : わかりやすい名前を入力 − Auto Scalingのガイダンス : チェック
- AMI : 手順3で作成したAMIを選択 − セキュリティグループ : 手順1-3で作成したセキュリティグループを選択
他はデフォルト値で問題ありません。
以上で起動テンプレートが作成されるので次にAuto Scaling Groupを作成します。
手順6-3). サイドバーのAuto Scaling > Auto Scalingグループ
と進み、Auto Scalingグループを作成する
を押下して作成画面へ進む。
手順6-4). 起動テンプレート作成の画面へ進むので、Auto Scalingグループ名
にわかりやすい名前を入力し、起動テンプレート
で手順5−2で作成した起動テンプレートを選択する。
手順6-5). 設定の構成へ進むので、購入オプションとインスタンスタイプ
では運用に併せてインスタンスの分散
とインスタンスタイプ
を設定する。
- ネットワーク
- VPC : 適切なVPCを選択
- サブネット : 可用性を高めるために2つ以上選択(手順5−3で設定したALBと同一にする)
手順6-6). 詳細オプションを設定の画面に進むので設定を行い次へ
を押下する。
- ロードバランシング :
ロードバランシングの有効化
をチェックし、Application Load Balancer または Network Load Balancer
を選択 - ロードバランサーのターゲットグループを選択 : 手順5−6で設定したロードバランサーのターゲットグループを選択
- ヘルスチェック :
ELB
をチェック - モニタリング :
CloudWatch 内でグループメトリクスの収集を有効にする
をチェック
手順6-7). グループサイズとスケーリングポリシーを設定する画面に進むので、ここも運用に併せてグループサイズ
、スケーリングポリシー
、スケールイン保護
を設定する。次の通知の設定、タグの設定も運用に併せて設定する。
以上でAuto Scaling Groupが作成されます。グループサイズやスケーリングポリシーは運用を行っていく中で最適値がわかると思いますのでその都度設定を変更していけば良いと思います。
ここまでの設定で最初に示した本番環境の構成が出来上がりです。設定が終わってしばらくするとインスタンスが立ち上がりターゲットグループでターゲットを確認するとhealthy
になります。
この状態になればALB経由でアクセスできるようになるので実際にアクセスして確かめて見たいと思います。
確認
実際に出来上がった環境でリクエストを送り正しいレスポンスが返ってくるかを確認します。なおテストのためALB配下のインスタンスはスケールアウトして3台起動した状態でテストしてみます。
管理画面の確認
ALBで設定したSSL証明書のドメインでアクセスしてみます。
直接CData API ServerをインストールしたEC2にアクセスするのと変わりなくログイン画面が表示されます。またALBにSSL証明書を設定したのでhttpsでアクセスできているので暗号化もできています。
AMI作成時に設定した管理者アカウントでも問題なくログインできます。
またリソース、接続先、ユーザーなども共有できています。
リクエストとレスポンスの確認
開発環境ですとEC2のアドレスを使用して直接インスタンスにリクエストを送っていましたが、リクエストの送信先もALBに向けます。
リクエスト1
curl --header "x-cdata-authtoken: MY_AUTH_TOKEN" "https://{独自ドメイン}/api.rsc/world_country/"
レスポンス1
{ "@odata.context": "https://{独自ドメイン}/api.rsc/$metadata#world_country", "value": [ { "Code": "ABW", "Capital": 129, "Code2": "AW", "Continent": "North America", "GNP": 828.00, "GNPOld": 793.00, "GovernmentForm": "Nonmetropolitan Territory of The Netherlands", "HeadOfState": "Beatrix", "LifeExpectancy": 78.4, "LocalName": "Aruba", "Name": "Aruba", "Population": 103000, "Region": "Caribbean", "SurfaceArea": 193.00, "IndepYear": null }, { "Code": "AFG", "Capital": 1, "Code2": "AF", "Continent": "Asia", "GNP": 5976.00, "GovernmentForm": "Islamic Emirate", "HeadOfState": "Mohammad Omar", "IndepYear": 1919, "LifeExpectancy": 45.9, "LocalName": "Afganistan/Afqanestan", "Name": "Afghanistan", "Population": 22720000, "Region": "Southern and Central Asia", "SurfaceArea": 652090.00, "GNPOld": null }, { "Code": "AGO", "Capital": 56, "Code2": "AO", "Continent": "Africa", "GNP": 6648.00, "GNPOld": 7984.00, "GovernmentForm": "Republic", "HeadOfState": "José Eduardo dos Santos", "IndepYear": 1975, "LifeExpectancy": 38.3, "LocalName": "Angola", "Name": "Angola", "Population": 12878000, "Region": "Central Africa", "SurfaceArea": 1246700.00 }, ... ] }
今までと変わりなく問題なくレスポンスが返ってきます。
まとめ
CData API ServerをAWS上に本番環境想定の環境を構築してみました。 CData API Serverを検討している方は「HTTPS化」、「可用性と耐障害性を向上」を満たせましたのでこの構成で本番運用をしてみてはいかがでしょうか?
最後まで読んで頂いてありがとうございました。